home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 1136 < prev    next >
Text File  |  1994-08-27  |  3KB  |  72 lines
  1. Subject: GEM List
  2. Subject: Re: Gem List
  3. Date: Sun, 31 Jul 94 19:09 EST
  4. From: "Daniel J. Hollis" <0006795560@mcimail.com>
  5. To: ems <gem-list@world.std.com>
  6. Subject: GEM List
  7. Message-Id: <72940801000927/0006795560PK2EM@mcimail.com>
  8. Precedence: bulk
  9.  
  10. Subject: Re: Gem List
  11.  
  12. Anonymous again:
  13. ----------------
  14. > I do not have a copy of XAES.  I heard about a wordprocessor or something 
  15. > for the Atari that would pop up a menu when you clicked on the closer.
  16.  
  17. You were talking like you have it.
  18.  
  19. > And BTW, I am STRONGLY against replacing the standard window gagets.
  20.  
  21. Then don't use our library.  Like I said though, you can switch the custom
  22. windows on or off if you wish.
  23.  
  24. > I haven't taken the time to figure out WF_BEVENT.  I will soon for the 
  25. > sake of knowing it, but so far I don't seem to need it which is just 
  26. > great by me because not everyone will be running an OS with WF_BEVENT.
  27.  
  28. Because you're too lazy, obviously.  WF_BEVENT is a piece of cake to learn,
  29. and if you can't take the simple 5 minutes of any day to figure out how to
  30. do it, then I wonder about your credibility as a GEM coder.  Ask ANYONE on
  31. here how they feel about WF_BEVENT.  They will tell you they love it.
  32. (Except you of course.)
  33.  
  34. > I understand now.  Do you then do 3-d gagets on all windows even on older 
  35. > TOS versions?  This WOULD be a benefit.
  36.  
  37. Yes.  I do 5 3D drawing styles, in fact, and you can choose them on the fly.
  38. In fact, this is one of the FIRST things we did in XAES.
  39.  
  40. > I'm not lazy... just practical.  Before I write code, I will often sit 
  41. > down and work the whole thing out in my mind or on paper before I begin.  
  42.  
  43. Just like you did with WF_BEVENT?
  44.  
  45. > I go for the most ellegant approach.  The most ellegant isn't necessarily 
  46. > the most efficient, code-wise, but it takes the least time for me, is 
  47. > often smaller, requires less typing, and is far less bug-prone.
  48.  
  49. The "most elegant" to me sounds like "the laziest". I.e. put the least amount
  50. of effort in doing something. If you're going to do something, why not spend
  51. the time doing it RIGHT? Rather than a half-hearted attempt at doing the bare
  52. minimum?
  53.  
  54. > Parcing ASCII is not my most favorite thing to do.  I can do it, but I 
  55. > don't think it's very enjoyable.  Therefore, I'm a bit more likely to not 
  56. > do it too well, due to lack of experience.  (not that I wouldn't TRY, 
  57. > though.)  Whatever is required to parce this file and deal with it WILL 
  58. > be included in my library in some form or other, so don't worry about it.
  59.  
  60. Parsing ASCII is simple! Besides the fact that once the APP_DEFS standard
  61. gets finished, people can write support into their libraries for it -- so
  62. that the programmer doesn't have to parse the APP_DEFS file, he will have
  63. pre-written routines in the library to do it for him.
  64.  
  65. I'm not worrying about any parsing of files or any code on your part. I have
  66. requested that this be done, and someone code it and post it in "Pseudo code"
  67. or in C code so everyone can use it.  Hopefully, we'll have it posted in
  68. English, and not in German...  @_@
  69.  
  70. -- Ken Hollis (Bitgate Software)
  71.  
  72.